1. Field of the Invention
The present invention relates generally to network architectures. More particularly, the present invention relates to methods and systems for implementing a light-weight TCP stack for use in networks.
2. Background Art
Today, the Internet uses a variety of technologies to provide end-to-end communication between applications on different computers. Most applicants use Transport Control Protocol (TCP) and Internet Protocol (IP) (TCP/IP) to achieve this end-to-end communication. TCP/IP is a suite of protocols designed to allow communication between networks regardless of the technologies implemented in each network. The concept that underlies the creation and development of TCP/IP is generally referred to as internetworking. An important fundamental idea that defines the internetworking is known as layering or modularity. For example, FIG. 3 of the present application illustrates various layers of TCP/IP stack 300.
As shown in FIG. 3, TCP/IP stack 300 includes application layer 305, transport layer 310, network layer 315, data-link layer 320 and physical layer 325. Application layer 305 is a user process cooperating with another process on the same or a different host. Examples of application layer 305 include telnet (protocol for remote terminal connections), FTP (file transfer protocol), RPC (remote procedure calls), SMTP (e-mail), TFTP (trivial file transfer protocol), DNS (domain name server) and NFS (network file system). Transport layer 310 provides end-to-end data transfer. The most common example transport layer 310 protocols are TCP, UDP (User Datagram Protocol) and ICMP (Internet Control Message Protocol). Network layer 315 provides a virtual network image of the internetwork and, in doing so, shields the higher layers from the lower network structure. IP is the best known of network layer 315 protocols. Data-link layer 320 provides an interface to the actual network hardware. TCP/IP can use almost any protocol present at this point, which is made possible by the flexibility provided from the IP layer. For example, the protocol IEEE 802.2 is used as an API (Application Program Interface) for connection to the IEEE 802.3 ethernet. Lastly, physical layer 325 is purely the hardware layer, such as the cable, radio-wave, satellite and network interface card.
As a packet is received by a host, the packet enters the lowest point of TCP/IP stack 300, which is physical layer 325, and travels the sequence of layers 305-325 that make up TCP/IP stack 300. Each layer then proceeds to strip-out the data it needs and passes the remaining packet, if required, to the next layer up in the stack. Likewise, when application layer 305 creates a packet, application layer 305 will pass the packet down to the next layer where further information is added by each and every subsequent layer until the packet emerges onto physical layer 325 as a full TCP/IP packet. As an example, a 30-byte packet created by application layer 305 may be sent to transport layer 310, e.g. TCP, where 20 bytes of TCP header are added to the packet. Thereafter, 20 bytes of IP header may be added by network layer 15 to the packet, and 22 bytes of ethernet header may be added by data-link layer 320, before a full packet of 96 bytes arrives at physical layer 325 for transmission in the network. Similarly, when a packet arrives at physical layer 325, data are stripped out from the packet at each layer until a 30-byte packet arrives at application layer 305.
Now, turning to FIG. 1, it illustrates conventional network communication 100 using full TCP stack implementations at each end of the network. Edge device 110, such as a load-balancer, firewall or a NAT (Network Access Translation) device, often sits at the edge of the network for terminating client TCP connections 105 and providing a bridge to servers 120, 130 and 140 via private connections 116, 117 and 118. As shown, edge device 110 includes full TCP stack implementation (FTSI) 115 for establishing a plurality of FTSI private connections with each of the plurality of servers 120, 130 and 140, where each server 120, 130 and 140 also includes FTSI 125, 135 and 145, respectively, for supporting FTSI private connections 116, 117 or 118. For example, when edge device 110 receives a client connection request, edge device 110 transmits a request to one of servers 120, 130 or 140 for establishing a private connection 116, 117 or 118, respectively, using a full-blown TCP stack implementation. In other words, each and every M1 connections 116, M2 connections 117 and M3 connections 118 is supported by a full-blown TCP stack implementation at each respective server 120, 130 and 140, where N client connections 105 is equal to the total of M1 connections 116, M2 connections 117 and M3 connections 118. In other words, if M1 connections include five connections, and five full-blown TCP sessions are initiated to support the five connections. This conventional network architecture, however, is quite inefficient and burdensome for servers 120, 130 and 140, and edge device 110, because an excessive amount processing overhead is created for each private connection that is supported by an end-to-end full-blown TCP stack implementation. For example, on a per-session basis, each full-blown TCP stack implementation includes a full-fledged socket/TCP/IP data structure, retransmission handling, timer management, populated lookup table, session open and tear-down, and so on.
FIG. 2 illustrates conventional network communication 200 including edge device 110 and server 120. Edge device includes listening socket 210 for monitoring client request for a TCP/IP connection. When edge device 110 receives a client connection request using listening socket 210, edge device 110 starts a thread, such as a thread 212, 222 or 232, for establishing a TCP/IP session for a connection with the client for supporting a client connection, such as client connection 202, 204 or 206, and also for establishing a TCP/IP session for supporting a connection with server 120. Edge device 110 creates a socket shown in FTSI/socket 215 for a client connection, and creates a socket shown in FTSI/socket 218 for a connection with server 120, such as private connection 242, 244 or 246.
A socket is required on each of edge device 110 and server 120 for a valid connection, i.e. two sockets per connection, and each of edge device 110 and server 120 will keep track of the sockets currently in use. Each socket contains the numeric IP address of the local host, the local port number and the port number of the TCP/IP service on the remote host. Each socket is uniquely numbered and valid only for the duration of the connection. The socket number is recycled when the connection is completed. When server 110 sends a connection request to server 120 asking for permission to use the remote service, server 120 uses listening socket 250 for monitoring and receiving such request to start a thread, such as thread 252, 262 or 272, for establishing a TCP/IP session for supporting a connection with edge device 110. The initial request from edge device 110 includes IP address of server 120, the port number of the requested service from server 120 and the local socket number, i.e. the originating socket number of edge device 110. As a result of this initial request, server 120 creates its own socket 255, 265 or 275 to use for the duration of the connection 242, 244 or 246, respectively. Server 120 then replies with an acknowledgement which contains server 120 socket information directed back to the originating socket address of edge device 110.
For example, once client connection 202 between edge device 110 and a client using the socket in FTSI/socket 215 is established and confirmed, FTSI/socket 215 provides a full implementation of TCP stack for data communications between the client device and edge device 110. Similarly, once private connection 242 between edge device 110 and server 120 using the sockets in FTSI/socket 218 and FTSI/socket 255 is established and confirmed, FTSI/socket 218 and FTSI/socket 255 provide full implementations of TCP stack for data communications between edge device 110 and server 120. At this point, the client can then use the desired application on server 120. When the client ends the connection with edge device 110, edge device 110 in turn ends the connection with server 120. Likewise, client connections 204 and 206 can made via FTSI/socket 225 and FTSI/socket 235, respectively, and private connections 244 and 246 can made via FTSI/socket 228, FTSI/socket 265, FTSI/socket 238 and FTSI/socket 275, in response to other client requests through edge device 110 for using services or applications on server 120.
However, the above-described conventional approach suffers from many inefficiencies and a tremendous overhead for edge device 110 and server 120, since each of private connections 242, 244 and 246 must be supported by a full TCP stack implementation at edge device 110 and a full TCP stack implementation at server 120, e.g. FTSIs of FTSI/socket 218, 228 and 238 and FTSIs of FTSI/socket 255, 265 and 275. As a result, on a per-session-basis, each full-blown TCP stack implementation—in this case three sets of FTSI to support three private connections—includes a tremendous overhead of a full-fledged socket/TCP/IP data structure, retransmission handling, timer management, populated lookup table, session open and tear-down, and so on.
Accordingly, there is a need in the art to provide a higher performance and resource efficient network architecture that overcomes the inefficiencies of the conventional network architecture and its undesirable full TCP stack overhead that is required for each connection.